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ABSTRACT 

The  US  Department  of  Defense  (DoD)  is  currently  launching  itself  into  the  Global  Information  Grid  (GIG)  envi¬ 
ronment.  Although  we  may  not  know  the  full  shape  of  the  GIG  or  even  it’s  implication  for  Modeling  and  Simula¬ 
tion  (M&S)  at  this  point,  there  are  some  significant  aspects  of  the  GIG  upon  which  we  can  build  to  become  capable 
participants  in  this  new  world.  The  Defense  Information  Systems  Agency  (DISA),  which  is  the  organization  re¬ 
sponsible  for  building  the  GIG,  and  the  Defense  Modeling  &  Simulation  Office  (DMSO),  which  is  the  focal  point 
for  M&S  in  DoD,  teamed  to  provide  critical  technical  and  operational  concepts  that  have  the  potential  to  change 
dramatically  the  way  we  look  at  distributed  simulation.  Regardless  of  how  the  GIG  finally  emerges,  we  know  cer¬ 
tainly  that  it  will  be  based  on  a  Service-Oriented  Architecture  (SOA).  The  GIG  comprises  four  domains  that  are 
used  to  group  and  categorize  the  services.  DISA  is  actually  working  on  standards,  service  stacks,  and  service  defi¬ 
nitions.  These  standards  and  definitions  will  provide  the  core  upon  which  we  build  M&S  services  in  the  future.  We 
will  describe  how  using  these  services  will  change  the  way  we  look  at  M&S  standards;  how  existing  and  emerging 
data  models  provide  a  critical  part  of  the  solution;  and  where  we  are  going  with  the  HLA.  In  particular  we  will  ex¬ 
ploit  web  services,  as  they  are  currently  the  choice  for  implementing  SOA.  Topics  included  are  the  web  service 
stack;  standards  being  adopted  by  the  GIG  and  their  implication  for  service  providers;  how  ontologies,  taxonomies 
and  data  models  play  in  web  services;  what  standard  data  models  are  being  used;  how  M&S  needs  to  look  at  stan¬ 
dards  in  the  light  of  GIG  services;  and  how  this  affects  the  review  of  the  IEEE1516  HLA  standard. 
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Introduction 

In  order  to  leverage  the  power  of  information,  the  in¬ 
formation  has  to  be  efficiently  and  effectively  distrib¬ 
uted  and  utilized  in  a  parallel  manner.  Within  the 
armed  forces,  this  task  is  pursued  by  Network  Centric 
Operations  and  Warfare  (NCOW).  NCOW  provides  a 
force  with  access  to  a  new,  previously  unreachable 
region  of  the  information  domain.  The  ability  to  oper¬ 
ate  in  this  region  provides  the  Warfighter  with  a  new 
type  of  information  advantage  leading  to  a  Command 
and  Control  (C2)  advantage.  This  advantage  is  en¬ 
abled  by  dramatic  improvements  in  information  shar¬ 
ing  made  possible  via  networking.  With  this  informa¬ 
tion  advantage,  a  warfighting  force  can  achieve  dra¬ 
matically  improved  shared  situational  awareness  and 
knowledge.  The  transformation  of  C2  procedures  goes 
hand  in  hand  with  these  technical  achievements.  Al¬ 
though  technology  is  the  enabler,  the  driving  factor  is 
the  transformation  of  the  forces  as  a  whole. 

In  this  context,  the  ability  to  achieve  a  heightened  state 
of  shared  situational  awareness  and  knowledge  among 
all  elements  a  force,  including  allied  and  coalition  part¬ 
ners,  is  increasingly  viewed  as  a  cornerstone  of  Com¬ 
mand,  Control,  Communications,  Computers,  Intelli¬ 
gence,  Surveillance  and  Reconnaissance  (C4ISR) 
transformation.  Emerging  evidence  from  recent  mili¬ 
tary  operations  and  a  broad  range  of  experimentation 
supports  the  relationship  between  shared  situational 
awareness  and  knowledge  enabled  by  NCOW  concepts 
and  increased  combat  power. 

The  means  for  accomplishing  this  in  the  U.S.  Depart¬ 
ment  of  Defense  (DoD)  is  the  Global  Information  Grid 
(GIG).  The  GIG  is  a  globally  interconnected,  end-to- 
end  set  of  information  capabilities,  associated  proc¬ 
esses  and  personnel  through  which  information  is  col¬ 
lected,  processed,  managed,  stored  and  disseminated 
on  demand  to  Warfighters,  policy  makers,  and  support 
personnel. 


The  GIG  is  a  key  enabler  of  NCW  and  is  essential  for 
information  and  decision  superiority.  It  will  enable 
C4I  integration  of  joint  forces,  improve  interoperability 
of  systems,  and  increase  optimization  of  bandwidth 
capacity  thereby  dramatically  improving  warfighting 
capabilities.  The  GIG  will  enhance  operational  capa¬ 
bilities  while  providing  a  common  environment  for 
Command  and  Control  (C2),  combat  support,  combat 
service  support,  intelligence,  and  business  functions. 

The  next  generation  of  information  technology  (IT) 
supporting  Joint  Command  and  Control  (JC2)  must  be 
much  more  agile  than  the  C4ISR  systems  are  today. 
The  stand-alone,  database  centric  and  message  based 
methods  of  informing  the  Commander  ended  with  the 
concept  of  the  Common  Operational  Picture  (COP). 
However,  the  COP  is  still  a  quasi-static  display  of  the 
situation,  with  latency  issues  and  in  the  best  case,  a 
geo-spatial  representation  of  logistics  and  intelligence 
data.  What  the  Warfighter  needs  for  JC2  is  an  agile 
process,  i.e.,  tools  that  are  bridging  the  gap  between 
the  information  domain  and  the  cognitive  domain. 
There  is  a  clear  requirement  in  the  various  components 
of  a  Net  Centric  C4I  system  to  utilize  Models  and 
Simulations  (M&S).  These  can  be  the  basis  for  plan¬ 
ning  and  decision  support  tools,  as  well  as  the  informa¬ 
tion  processing  required  for  visualization  and  presenta¬ 
tion  of  information  outside  the  normal  COP’s  physical, 
geo-spatial  domain.  There  are  explicit  and  implicit 
requirements  for  sophisticated  processing  of  that  in¬ 
formation  for  situational  awareness,  decision  support, 
and  operational  control.  Additional  requirements  are 
to  seamlessly  support  training,  procurement  of  new 
components,  and  testing;  in  other  words,  the  supply  of 
M&S  functionality  across  the  operational  context  of 
the  GIG. 

This  tutorial  shows  the  necessity  for  operational  M&S 
services  within  the  GIG.  It  will  show  the  general  tech¬ 
nical  constraints  of  service-oriented  architectures  and 
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web-  or  grid-services,  and  it  will  give  a  first  overview 
of  the  military  GIG  in  the  detail  needed  for  the  M&S 
component-  or  service-developer  to  be  aware  of  chal¬ 
lenges  and  requirements.  The  reference  section  gives 
an  initial  selection  of  literature  in  this  area. 


OPERATIONAL  REQUIREMENS  FOR  M&S 
SERVICES  FOR  NCOW 

In  addition  to  the  well-known  and  valid  arguments  to 
couple,  embed,  or  integrate  Command  and  Control 
systems  and  simulation  systems  for  training  and  test¬ 
ing,  the  use  of  M&S  functionality  within  the  GIG  is 
directly  connected  to  an  improvement  of  the  NCOW 
value  chain.  In  order  to  show  how  this  improvement  is 
motivated,  the  value  chain  approach,  which  employs 
several  layered  concepts,  must  be  defined: 

•  The  value  chain  starts  with  Data  Quality  de¬ 
scribing  the  information  within  the  underlying 
command  and  control  systems. 

•  Information  Quality  tracks  the  completeness, 
correctness,  currency,  consistency,  and  preci¬ 
sion  of  the  data  items  and  information  state¬ 
ments  available. 

•  Knowledge  Quality  deals  with  procedural 
knowledge  and  information  embedded  in  the 
command  and  control  system  such  as  tem¬ 
plates  for  adversary  forces,  assumptions  about 
entities  such  as  ranges  and  weapons,  and  doc¬ 
trinal  assumptions,  often  coded  as  rules.  In 
future  systems,  this  agile  component  could  be 
presented  by  M&S  systems.  Knowledge  qual¬ 
ity  is  the  first  component  related  to  the  com¬ 
mon  model  of  the  operation. 

•  Finally,  Awareness  Quality  measure  the 
degree  of  using  the  information  and 
knowledge  embedded  within  the  command 
and  control  system.  Awareness  is  explicitly 
placed  in  the  cognitive  domain,  i.e.,  definitely 
above  the  level  of  technical  interoperability. 

In  summary,  the  ability  to  share  data,  information, 
knowledge,  and  awareness  enables  conducting  opera¬ 
tions  more  efficiently.  The  IT  value  chain  reflecting 
the  C4ISR  improvements  over  the  recent  decades  mir¬ 
rors  the  NCW  value  chain.  The  current  C4ISR  systems 
started  as  database  centric  and  message  driven  solu¬ 
tions.  They  were  only  able  to  support  Data  Quality. 
To  support  the  next  level  within  the  value  chain,  the 
idea  of  the  Common  Operational  Picture  (COP)  had  to 
be  introduced.  This  led  to  a  jump  in  the  quality,  i.e., 
increasing  it  by  an  order  of  magnitude  (“a  picture  says 
more  than  1,000  words”).  The  reason  is  that  the  COP 


added  context  to  the  data,  hence  increased  not  only  the 
Data  Quality,  but  also  Information  Quality.  The  intro¬ 
duction  of  M&S  to  C4ISR  adds  procedural  knowledge 
in  form  of  models;  hence,  the  next  level  in  the  value 
chain  can  be  supported,  leading  to  another  improve¬ 
ment  (“a  simulation  says  more  than  1,000  pictures?”). 
Finally,  if  the  M&S  services  and  components  are  en¬ 
riched  by  the  necessary  metadata  describing  not  only 
the  model,  but  also  its  constraints,  data  requirements, 
etc.,  in  the  future,  intelligent  software  agents  will  be 
able  to  select  applicable  M&S  services  to  permanently 
evaluate  the  situation,  work  on  alternatives,  cope  with 
alternative  courses  of  actions  of  hostile  forces,  etc. 
This  will  equal  the  use  of  knowledge  embedded  in  the 
system;  in  other  words,  even  the  awareness  quality 
may  be  supported  by  future  C4SIR  systems.  Figure  1 
depicts  this  idea. 

The  integration  of  M&S  components  into  the  IT  infra¬ 
structure  is  therefore  seen  as  an  operational  necessity. 
The  technical  requirements  are  given.  As  with  the  ac¬ 
ceptance  of  NCOW,  the  integration  of  M&S  into  the 
GIG  faces  more  cultural  barriers  than  technical  chal¬ 
lenges. 

SERVICE-ORIENTED  ARCHITECTURES,  WEB 
SERVICES,  AND  M&S  SERVICES 

The  current  software  paradigm  to  cope  with  the  chal¬ 
lenges  of  net-centric  operations  such  as  NCOW  is  to 
apply  services  within  service-oriented  architectures 
(SOA).  SOA  is  a  collection  of  composable  services. 
A  service  is  a  software  component  that  is  well  defined, 
both  from  the  standpoint  of  software  and  operational 
functionality.  In  addition,  a  service  is  independent, 
i.e.,  it  doesn't  depend  on  the  context  or  state  of  any 
application  that  calls  it. 

Currently,  these  services  are  typically  implemented  as 
web  services.  Services  in  grids  are  often  referred  to  as 
grid  services.  Although  different  standards  may  be 
used  for  the  implementation  of  the  service,  web  ser¬ 
vices  and  grid  services  are  used  as  synonyms  in  this 
tutorial.  The  advantage  of  using  web  standards  in  an 
SOA  is  that  the  services  can  more  easily  handle  dis¬ 
tributed  applications  in  heterogeneous  infrastructures. 
Nothing  in  particular  has  to  be  done  programmatically 
to  the  service,  except  to  enable  it  to  receive  requests 
and  transfer  results  using  web-based  messaging  and 
transportation  standards.  In  many  cases,  web  services 
are  straightforward  and  existing  software  can  easily  be 
“web  enabled”  to  create  new  services  usable  within  an 
SOA. 
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Figure  1.  Improving  the  NCOW  Value  Chain 


The  Standards  of  the  Web-Service  Stack 

Web  Services  are  a  set  of  operations,  modular  and  in¬ 
dependent  applications  that  can  be  published,  discov¬ 
ered,  and  invoked  by  using  industry  standard  protocols 
-  Simple  Object  Access  Protocol  (SOAP),  Web  Service 
Description  Language  (WSDL)  and  Universal  Distri¬ 
bution  Discovery  and  Interoperability  (UDDI).  It  is  a 
distributed  computing  model  that  represents  the  inter¬ 
action  between  program  and  program,  instead  of  the 
interaction  between  program  and  user.  Web  services 
can  also  be  defined  as  discrete  Web-based  applications 
that  interact  dynamically  with  other  web  services.  In 
order  to  make  this  happen,  several  sub-functions  are 
necessary: 

•  Self-description  of  the  service  functionality. 

•  Publishing  the  service  descriptions  using  a 
standardized  format. 

•  Locating  the  service  with  the  required  func¬ 
tionality. 

•  Establishing  communications  with  the  ser¬ 
vice. 

•  Requesting  the  required  data  to  initiate  the 
service. 

•  Exchanging  data  with  other  web  services,  in¬ 
cluding  delivering  the  results. 


The  web  service  vision  is  that  services  will  work  to¬ 
gether  seamlessly  because  they  are  developed  to  the 
same  standards  for  self-description,  publication,  loca¬ 
tion,  communication,  invocation,  and  data  exchange 
capabilities.  As  all  the  standards  concerned  are  open, 
the  technologies  chosen  for  web  services  are  inherently 
neutral  to  compatibility  issues  that  exist  between  pro¬ 
gramming  languages,  middleware  solutions,  and  oper¬ 
ating  platforms.  As  a  result,  applications  using  web 
services  can  dynamically  locate  and  use  necessary 
functionality  -  whether  available  locally  or  from  across 
the  Internet. 

Web  services  are  discrete  web-based  applications  that 
interact  dynamically  with  other  web  services.  Four 
elementary  definitions  are  needed.  These  definitions 
are  directly  based  on  open  standards: 

•  Structuring  and  describing  the  information  to 
be  exchanged. 

•  Specifying  the  web  service  (self  description). 

•  Accessing  and  communicating  with  the  web 
service. 

•  Registering  and  locating  web  services. 

The  first  definition  describes  the  Structure  and  De¬ 
scription  of  the  Information  to  be  exchanged.  This  is 
done  using  the  Extensible  Markup  Language  (XML). 
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The  Object  Management  Group  website  gives  the  most 
recent  definitions  applicable  to  XML.  Numerous  addi¬ 
tional  publications  deal  with  XML.  Like  the  Hypertext 
Markup  Language  (HTML),  XML  is  directly  related  to 
the  more  general  Standard  Generalized  Markup  Lan¬ 
guage  (SGML).  XML  expanded  the  browser-oriented 
use  of  the  Internet  in  which  services  provide  informa¬ 
tion  to  a  user  via  HTML,  by  enabling  service-to- 
service  communication.  This  paradigm  uses  the  Inter¬ 
net  as  a  communication  backbone  without  requiring  a 
user  in  the  loop  to  drive  this  process.  Wherever  data 
must  be  exchanged  between  two  services  or  applica¬ 
tions,  XML  can  be  the  suitable  format  for  making  the 
data  self-describing. 

XML  can  be  seen  as  the  foundation  on  which  web  ser¬ 
vices  are  built.  It  provides  the  description  of  the  data 
to  be  exchanged  as  well  as  storage  and  transmission 
formats.  It  also  supports  the  data  transformation  from 
legacy  data  representations  within  the  applications  to  a 
common  data  reference  and  exchange  model.  One  of 
the  frequently  used  arguments  against  the  application 
of  XML  is  that  XML  can  be  inefficient  due  to  its  use  of 
strings  based  on  Unicode  for  capturing  the  information. 
However,  ongoing  standardization  efforts  on  a  binary 
version  of  XML  will  help  to  overcome  this  problem. 
In  addition  to  XML  itself,  the  following  related  mem¬ 
bers  of  the  XML  family  are  of  particular  interest  for 
web  service  applications: 

•  XML  schemas  that  define  data  types,  content 
and  structure; 

•  XML  namespaces  that  unambiguously  define 
names; 

•  Extensible  Stylesheet  Language  Transforma¬ 
tion  (XSLT)  that  enable  standardized  trans¬ 
formation  of  various  XML  schemas  into  each 
other. 

The  second  definition  deals  with  Specifying  the  Web 
Sendee.  The  main  idea  behind  a  web  service  is  that, 
once  it  is  written,  it  can  be  published  and  registered  by 
the  provider.  Interested  users  can  then  locate  it  to  use 
the  functionality  provided.  To  this  end,  the  necessary 
information  about  the  functionality  of  the  web  service, 
its  location,  content,  the  structure  of  input  and  output 
data,  and  constraints  have  to  be  described.  This  is 
done  using  the  Web  Sendee  Description  Language 
(WSDL).  The  World  Wide  Web  Consortium  (W3C) 
coordinates  the  related  standardization  efforts  and  pub¬ 
lishes  the  results  on  its  website.  WSDL  comprises  data 
type  messages  for  data  type  definitions,  operations  port 
type  bindings  for  abstract  operations,  and  port  services 
for  service  bindings.  The  data  type  definitions  are 
XML  schemas.  A  port  type  is  a  logical  grouping  of 


operations,  similar  to  an  object’s  interface  descriptions 
in  the  Common  Object  Request  Broker  Architecture 
(CORBA).  A  port  is  used  to  expose  a  set  of  operations 
(as  specified  by  the  port  types)  using  a  given  transport 
mechanism.  Service  bindings  map  messages  and  op¬ 
erations  to  transport  mechanisms  needed  for  the  com¬ 
munication  when  using  the  services,  such  as  SOAP 
bindings,  which  will  be  dealt  with  in  the  next  para¬ 
graph.  In  other  words,  WSDL  specifies  what  opera¬ 
tions  and  services  can  be  called  by  specifying  which 
functions,  with  which  parameters,  delivering  results  via 
which  ports  in  which  format.  In  summary,  WSDL  uses 
XML  schemas  to  describe  what  input  parameters  are 
needed,  what  functions  can  be  called,  what  output  pa¬ 
rameters  have  to  be  expected,  and  which  protocols 
have  to  be  used  to  deliver  the  input,  to  invoke  the  func¬ 
tion,  and  to  receive  the  output. 

The  third  definition  is  necessary  to  Access  and  Com¬ 
municate  with  the  Web  Sendee.  The  related  standard  is 
the  Simple  Object  Access  Protocol  (SOAP).  As  with 
the  WSDL,  standardization  of  SOAP  is  orchestrated  by 
the  W3C.  This  specification  defines  a  message  frame¬ 
work  for  exchanging  data  in  XML  documents.  SOAP 
provides  a  minimum  level  of  transport  using  the  Hy¬ 
pertext  Transfer  Protocol  (HTTP),  Simple  Mail  Trans¬ 
fer  Protocol  (SMTP),  or  the  Multiple  Internet  Messag¬ 
ing  Extensions  (MIME)  multipart.  The  use  of  alterna¬ 
tive  communication  protocols  is  possible,  but  HTTP 
and  SMTP  are  actually  applied  in  most  circumstances. 

The  underlying  principle  of  SOAP  is  to  define  simple, 
one-way  mappings  for  basic  functions  like  GET  and 
POST  for  requesting  and  sending  information.  This 
information  is  contained  in  XML  formatted  messages. 
SOAP  defines  a  mandatory  envelope  and  body  that 
specifies  the  start,  content,  and  end  of  the  messages,  as 
well  as  obligatory  headers,  attachments,  encoding,  etc. 
SOAP  can  be  customized  with  Remote  Procedure  Call 
(RPC). 

The  last  definition  addresses  the  Registration  of  Web 
Sendees.  The  provider  of  the  web  service  must  publish 
its  description  in  form  of  the  WSDL  in  order  to  enable 
other  users,  including  web  services  themselves,  to  dis¬ 
cover  it.  To  this  end.  the  Universal  Distribution  Dis¬ 
covery  and  Interoperability  (UDDI)  framework  has 
been  established.  UDDI  is  not  a  formal  standard.  It  is, 
however,  a  comprehensive,  open,  industry  initiative 
resulting  in  a  directory  used  to  register  web  services 
(web  service  provider)  or  discover  them  (web  service 
user).  However,  UDDI  can  be  seen  as  something  like  a 
“de  facto”  standard  defining  a  data  model  in  form  of  an 
XML  schema  and  SOAP  application  programming 
interface  (API)  that  have  to  be  used  to  register  or  dis- 
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Figure  2.  Web  Services 


cover  a  web  service.  An  industry  consortium  founded 
by  Microsoft,  IBM,  and  Ariba  supports  UDDI. 

In  summary,  web  services  describe  their  information 
exchange  requests  in  form  of  XML  schemas,  they  are 
specified  using  the  WSDL,  and  they  communicate  us¬ 
ing  SOAP.  The  UDDI  registry  is  something  like  the 
Yellow  Pages  to  search  and  discover  available  web 
services  or  to  publish  additional  functionality  as  a  web 
service  provider.  Figure  2  shows  the  various  compo¬ 
nents  of  the  web  service  related  standards  framework. 

Web-Enabling  Components 

How  can  M&S  components  be  web-enabled?  The 
general  approach  is  easy,  and  particularly  so  when  the 
component  is  already  prepared  for  distributed  comput¬ 
ing.  Figure  3  illustrates  this  process. 

•  First,  the  input  and  output  data  must  be  speci¬ 
fied.  Data  modeling  -  the  unambiguous  defi¬ 
nition  of  all  entities  and  their  relations  -  is 
needed.  Even  without  a  data  model,  the  in¬ 
formation  to  be  exchanged  must  be  unambi¬ 
guously  defined. 

•  Second,  the  an  XML  interface  must  be  build 
to  import  and  export  the  data  as  specified  in 


the  first  step.  Furthermore,  the  procedures  in¬ 
voked  to  use  the  data  (or  produce  them)  must 
be  specified  using  XML  descriptions. 

•  In  the  third  step,  these  XML  descriptions  are 
form  the  basis  of  the  WSDL  description  of  the 
services  provided  by  the  component.  In  addi¬ 
tion  to  the  procedures  and  data,  descriptions 
of  ports,  network  addresses,  bindings  and  port 
types  supported  have  to  be  added  into  the  re¬ 
spective  fields  of  the  WSDL  schemas. 

•  This  result  describes  the  web  service  -  or  web 
services  -  delivered  by  the  component.  The 
only  thing  left  to  do  is  to  post  it  to  the  UDDI 
server  identified  for  the  supported  grid  or  net¬ 
work.  Users  will  look  up  WSDL  descriptions 
using  the  same  UDDI  server  and  can  connect 
to  and  invoke  the  web  services  using  the  in¬ 
formation  specified  in  the  WSDL  block. 

Projects  within  the  Extensible  M&S  Framework 
(XMSF)  program  have  shown  the  feasibility  of  this 
approach  for  M&S  components.  The  next  step  is  to 
bring  this  these  M&S  services  into  the  GIG  to  support 
the  warfighter. 
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THE  GLOBAL  INFORMATION  GRID 

This  section  gives  a  brief  introduction  to  the  ideas  un¬ 
derlying  the  GIG.  It  is  divided  into  a  technical,  func¬ 
tional,  and  an  organizational  view.  These  views  over¬ 
lap  and  all  three  of  them  are  necessary  to  understand 
the  role  of  the  GIG  in  support  of  the  concept  of  JC2. 
The  main  idea  of  JC2  is  that  information  is  obtainable 
by  the  Warfighter  “ Wherever  he  is,  Whatever  he  does, 
and  Whichever  system  he  uses.”  To  this  end,  techni¬ 
cally  interoperable  and  conceptually  composable  ser¬ 
vices  relevant  to  the  full  range  of  application  domains 
must  be  brought  together  in  a  distributed,  heterogene¬ 
ous,  information  technology. 

It  should  be  pointed  out  that  one  of  the  main  changes 
with  the  introduction  of  the  GIG  is  a  change  in  the  in¬ 
formation  policy.  The  GIG  mandates  that  information 
will  be  posted  immediately  and  will  be  available  to 
every  potential  user  without  processing.  The  rationale 
behind  this  new  concept  is  two-fold.  First,  even  raw, 
potentially  incomplete  data  can  empower  many  uses  in 
a  time-constrained  environment,  and  in  fact,  the  knowl¬ 
edge  gained  balances  the  risk  inherent  in  not  waiting 
for  the  processed  information.  Second,  data  distribu¬ 
tors  may  not  be  aware  of  all  potential  users  of  their 
data.  The  unidentified  user  would  never  be  reached  by 
the  traditional  data  distributions  paradigm  of  pushing 
data  from  the  provider  to  the  user.  Currently,  the  Task, 
Process,  Exploit,  Disseminate  (TPED)  concept  used  in 


many  services  to  provide  information  from  the  pro¬ 
ducer  to  the  consumer.  The  new  paradigm  will  be 
Task,  Post,  Process,  Use  (TPPU).  The  transition  from 
the  TPED  concept  to  the  TPPU  concept  leverages  in¬ 
formation  technology  and  connectivity  to  improve  the 
speed  and  quality  of  DoD  decision-making.  The  terms 
are  used  as  follows: 

•  Task:  As  in  TPED,  tasking  includes  user  re¬ 
quests  for  specific  information,  mission  man¬ 
agement  for  collection  platforms  and  sensor 
data  processing,  mission  planning,  and  ISR 
asset  allocation.  However,  in  TPPU,  tasking 
is  network  centric,  readily  accessible  to  all  au¬ 
thorized  users,  and  fully  integrated  with  user 
plans  and  operations. 

•  Post:  Data  providers  and  users  alike  post  data, 
information,  and  products  to  the  GIG  as  soon 
as  they  are  available.  Thus  authorized  users 
post  even  raw  data  on  the  network  for  use  be¬ 
fore  it  is  ingested  into  the  conventional  Proc¬ 
essing,  Exploitation,  and  Dissemination  proc¬ 
ess.  A  producer  of  information  makes  it 
available  to  others  by  placing  it  on  the  net¬ 
work  in  a  location,  form,  and  format  that  other 
users  expect.  Producers  of  information  are 
recognized  for  the  inputs  they  provide.  After 
using  information,  users  post  results  of  their 
work  back  to  the  network  for  others  to  proc¬ 
ess.  Finished  intelligence  products  are  dis- 
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seminated  as  they  were  under  TPED,  but  un¬ 
der  the  TPPU  paradigm,  information  and 
computing  power  is  continuously  shared  with 
users  over  high-bandwidth  network  commu¬ 
nications. 

•  Process:  In  TPED,  “processing”  normally  re¬ 
fers  to  the  data  handling  required  to  convert 
raw  sensor  data  to  a  useful  format.  In  TPPU, 
the  term  can  encompass  exploitation,  analysis, 
event  correlation,  and  fusion  of  data  and  in¬ 
formation.  Information  is  posted  directly 
from  a  sensor  to  a  user’s  portal  for  subsequent 
“processing.”  In  some  cases,  automated  in¬ 
formation  is  available  in  near  real  time.  In 
other  cases,  data  requires  additional  process¬ 
ing  by  the  user  to  extract  the  required  infor¬ 
mation. 

•  Use:  TPPU  gives  the  users  instant  access  to 
information.  Users  will  either  pull  informa¬ 
tion  from  known  portals  or  receive  informa¬ 
tion  based  on  profiles  or  procedures  such  as 
sensor-to-shooter.  This  places  a  dual  burden 
on  both  the  user  and  information  providers: 
Users  must  know  where  and  when  informa¬ 
tion  is  available  and  have  the  tools  and  capa¬ 
bilities  needed  to  retrieve  and  analyze  the  re¬ 
quired  information.  Automated  functions  will 
help  provide  this  capability.  Producers  must 
be  relevant  by  providing  value-added  infor¬ 
mation.  In  short  order,  producers  with  low  or 
non-existent  “hit  rates”  could  be  restructured 
or  eliminated  aiding  the  warfighter  by  ensur¬ 
ing  only  quality  sources  of  information  are 
available  on  the  net.  Finally,  users  can  share 
their  tailored  information  with  other  author¬ 
ized  users  by  posting  it  back  onto  the  network. 

Technical/Functional  View  of  the  GIG 

The  technical  backbone  actually  chosen  to  support  JC2 
is  the  GIG,  as  defined  in  DoD  Directive  8100.1.  The 
GIG  will  be  globally  interconnected,  end-to-end  set  of 
information  capabilities,  associated  processes,  and  per¬ 
sonnel  for  collecting,  processing,  storing,  managing, 
and  disseminating  information  on  demand  to  Warfight¬ 
ers,  policy  makers,  and  support  personnel.  The  GIG  is 
intended  to  include  all  owned  and  leased  communica¬ 
tions  and  computing  systems  and  services  (software, 
data,  security  services,  and  other  associated  services) 
necessary  to  achieve  Information  Superiority. 

The  GIG  will  be  Internet  Protocol  version  6  (IPv6) 
based,  which  means  that  the  service-oriented  architec¬ 
ture  is  likely  to  be  web  service-based,  leading  immedi¬ 
ately  to  an  extraordinary  role  of  XML  for  interopera¬ 


bility.  However,  the  implementation  of  the  GIG  is  not 
exclusively  committed  to  web  services.  Alternatives 
are  evaluated  as  well,  but  even  if  the  service  architec¬ 
ture  will  not  make  use  of  web  services,  the  role  of 
XML  for  information  exchange  between  the  services 
has  been  identified  as  one  of  the  main  interoperability 
enablers.  This  is  due  to  the  fact  that  XML  is  used  to 
define  the  namespaces,  the  ontologies  used  by  the 
communities  of  interest  for  the  exchange  of  informa¬ 
tion. 

This  development  led  to  the  establishment  of  the 
United  States  Department  of  Defense  (DoD)  XML 
Repository,  which  is  used  to  collect  all  relevant  XML 
tag  sets  used  within  DoD.  In  addition  to  the  DoD 
XML  Registry,  where  XML  tag  sets  are  simply  regis¬ 
tered,  the  DoD  established  the  “DoD  Metadata  Regis¬ 
try  and  Clearinghouse.”  The  DISA  website  places  the 
registry’s  objectives  in  context. 

“[The]  Defense  Information  Systems  Agency  (DISA)  is 
responsible  for  data  services  and  other  data-related 
infrastructures  that  promote  interoperability  and  soft¬ 
ware  reuse  in  the  secure,  reliable,  and  networked  envi¬ 
ronment  planned  for  the  DoD's  Global  Information 
Grid  (GIG).  The  Metadata  Registry  and  Clearing¬ 
house's  primary  objective  is  to  provide  software  devel¬ 
opers  access  to  data  technologies  to  support  DoD  mis¬ 
sion  applications.  Through  the  Metadata  Registry  and 
Clearinghouse,  software  developers  can  access  regis¬ 
tered  XML  data  and  metadata  components,  COE  data¬ 
base  segments,  and  reference  data  tables  and  related 
meta-data  information  such  as  Country  Code  and  US 
State  Code.  These  data  technologies  increase  the 
DoD's  core  capabilities  by  integrating  common  data, 
packaging  database  servers,  implementing  transforma¬ 
tion  media  and  using  Enterprise  data  services  built 
from  " plug-and-play "  components  and  data  access 
components.  ” 

The  definition  of  the  DoD  Discovery  Metadata  Speci¬ 
fication  (DDMS)  is  part  of  this  plan  and  a  very  impor¬ 
tant  step  towards  data-driven,  net-centric  interoperabil¬ 
ity.  The  metadata  is  grouped  into  four  categories, 
namely  security,  resource,  summary  content,  and  for¬ 
mat. 

•  Security  Set  elements  enable  the  description 
of  security  classification  and  related  fields  and 
provide  for  the  specification  of  security- 
related  attributes  and  may  be  used  to  support 
access  control. 

•  The  Resource  category  elements  provide  a 
way  to  describe  aspects  of  a  data  asset  that 
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support  maintenance,  administration,  and 
pedigree  of  the  data  asset. 

•  The  Summary  Content  categories  provide  the 
description  of  concepts  and  additional  contex¬ 
tual  aspects  of  the  data  asset  being  tagged  and 
include  such  elements  as  subject,  description, 
and  coverage. 

•  The  Format  elements  provide  the  description 
of  physical  attributes  of  the  asset  and  include 
elements  such  as  file  size,  bit-rate  or  frame- 
rate,  and  mime  type. 

The  actual  version  of  the  DDMS  provides  basic  Sum¬ 
mary  Content  elements  to  capture  content  metadata. 
Activities  are  underway  to  test  additional  Summary 
Content  elements  that  provide  a  more  robust,  struc¬ 
tured  method  of  describing  the  contents  of  a  resource. 
Candidates  for  addition  to  the  Summary  Content  Cate¬ 
gory  set  are  Person,  Place,  Organization,  Material,  and 
Event  elements. 

The  Net  Centric  Enterprise  Services  (NCES)  will  offer 
their  functionality  to  all  domains  of  all  communities  of 
interest.  Key  enterprise  services  will  include: 

•  Sendees  for  Messaging ,  which  is  the  ability  to 
exchange  information  among  users  or  applica¬ 
tions  on  the  enterprise  infrastructure  (e.g., 
Email,  Message  Oriented  Middleware,  AOL 


instant  messenger.  Wireless  Services,  Alert 
Services,  and  standardized  military  Message 
Text  Formats). 

•  Discovery  Sendees,  which  comprise  the  proc¬ 
esses  for  obtaining  information  content  or  ser¬ 
vices  by  exploiting  metadata  descriptions  of 
enterprise  IT  resources  stored  in  Directories, 
Registries,  and  Catalogs.  Search  engines  are  a 
subset  of  these  services. 

•  Mediation  Sendees  are  services  that  help  dis¬ 
seminating,  translating,  aggregating,  fusing, 
or  integrating  data  and  associated  metadata. 

•  Security  Sendees  comprise  capabilities  that 
address  vulnerabilities  in  networks,  services, 
capabilities,  or  systems. 

•  Storage  Sendees  mean  physical  and  virtual 
places  to  host  data  on  the  network  with  vary¬ 
ing  degrees  of  persistence  (e.g.,  archiving, 
content  staging). 

Organizational  View  of  the  GIG 

Five  Mission  Areas  have  been  identified  to  permit  us¬ 
ers  to  address  their  needs  and  related  development  ac¬ 
tivities  as  shown  in  Figure  4.  They  are  the  Warfighter 
and  the  Business  mission  areas,  the  Enterprise  Infor¬ 
mation  Environment  mission  area  and  two  Intelligence 
mission  areas  -  the  National  Intelligence  mission  area 
and  the  National  Intelligence  Enterprise  Information 
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Figure  4.  GIG  Mission  Areas 
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Environment  mission  area.  Each  of  these  Mission  Ar¬ 
eas  will  be  divided  into  domains  in  which  services  will 
be  developed.  The  domains  are  currently  being  de¬ 
fined. 

From  the  organizational  standpoint,  the  most  important 
idea  is  the  distinction  between  Core  Enterprise  Ser¬ 
vices,  which  are  applied  in  all  domains  and  which  are 
developed  and  maintained  centrally,  and  services  of  the 
different  Communities  of  Interests  (COI).  The  term 
“COI”  is  used  to  describe  any  collaborative  group  of 
users  who  must  exchange  information  in  pursuit  of 
their  shared  goals,  interests,  missions,  or  business 
processes,  and  who  therefore  must  have  shared  vo¬ 
cabulary  for  the  information  they  exchange.  While  the 
services  are  technically  identical,  the  organizational 
constraints  can  be  described  as  follows: 

•  Core  Enterprise  Services  are  provided  for  all 
participating  systems  and  services.  Whenever 
someone  needs  the  service  of  Data  Mediation 
or  Storage,  etc.,  the  same  core  service  must  be 
invoked,  no  matter  to  which  COI  the  user  be¬ 
longs  to. 

•  Community  of  Interest  Services  are  provided, 
implemented,  and  maintained  by  the  COI  for 
the  COI.  Namespaces,  unambiguous  defini¬ 
tions,  etc.,  are  specific  to  the  COI.  It  is  there¬ 


fore  possible  that  similar  services  are  imple¬ 
mented  in  the  various  COIs;  however,  they 
will  be  COI  specific  and  addressing  specific 
needs. 

As  there  is  no  technical  difference  between  a  CES  and 
a  COI  service.  Organizationally,  however,  the  distinc¬ 
tion  is  the  determining  factor  in  who  is  going  to  main¬ 
tain  and  update  the  service  in  the  future. 

As  COI  membership  may  include  various  data  owners 
and  producers  (e.g.  developers,  program  managers, 
subject  matter  experts,  users,  etc.)  who  need  to  share 
the  same  semantic  knowledge,  one  of  the  main  issues 
of  COI  services  is  enabling  a  common  understanding 
of  the  data  exchanged  between  the  services.  This  is 
established  by  a  common  name  space.  The  name  space 
management  efforts  of  all  COIs  are  based  on  the  Net- 
Centric  Data  Strategy  of  DoD.  To  enable  information 
sharing  between  different  communities,  mediation  ser¬ 
vices  are  provided  to  translate  between  the  different 
name  spaces.  Figure  5  shows  how  the  CES  and  COI 
services  are  organized  relative  to  the  GIG  user.  We 
define  the  terms  as  follows: 

•  GIG  Enterprise  Services  (GES):  Web-enabled 
capabilities  and  services  available  to  users 
(humans  and  systems)  on  the  GIG 


1C  (Title  50) 
a 


DoD  (Title  10) 


Users 


irl 


Warfiqhtinq 

Intelligence  C2 


Intel 


GIG  Enterprise  Services  (GES) 

Business 

Logistics 


SA 


Etc. 


ill 

ESM  Mediation  Messagi 

BHD 


Finance 


Personnel 


Etc. 


Community-of- 
C  Interest  (COI) 
'  Capabilities 


Communication 


Collaboration 


IN 


User 

Asst 


Backbone 


Core 
y  Enterprise 
'  Services 
(CES) 


Discovery  Security/IA  Storage  App  Hosting 

Net  Centric  Enterprise  Services  (PISA) 


Figure  5.  GIG  Services 
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•  Core  Enterprise  Services  (CES):  Fundamental 
set  of  computing,  networking,  and  data  shar¬ 
ing  services  provided  for  enterprise  user  sup¬ 
port 

•  Net-Centric  Enterprise  Sendees  (NCES):  Pro¬ 
gram  designated  to  provide  Core  Enterprise 
Services  on  the  GIG 

•  Domain:  Major  area  of  functional  responsibil¬ 
ity,  less  than  DoD  enterprise  scope,  compris¬ 
ing  persistent  requirements  and  resources, 
spanning  organizations  and  other  Communi¬ 
ties  of  Interest  (COIs) 

•  Community  of  Interest  (COI):  A  collaborative 
group  of  users  who  exchange  information  in 
pursuit  of  their  shared  goals,  interests,  mis¬ 
sions  or  business  processes 

Taking  into  account  the  description  of  the  GIG  just 
given,  there  are  significant  implications  for  future 
M&S  programs.  M&S  applications  and  services  pro¬ 
vided  by  programs  will  need  to  use  the  CES  services 
rather  than  develop  their  own.  M&S  programs  will 
also  need  to  participate  in  COIs  to  ensure  that  their 
data  is  visible  and  accessible  to  GIG  users. 


MODELING  &  SIMULATION  IN  THE  GIG 

This  last  section  introduces  the  notion  of  M&S  in  the 
context  of  the  GIG.  Issues  include  the  notion  of  M&S 
services  and  the  use  of  common  standards  and  proce¬ 
dures. 

Modeling  &  Simulation  Community  of  Interest 

As  pointed  out  earlier  one  of  the  main  organizational 
principles  is  the  use  of  Communities  of  Interest  (COI) 
of  GIG  users.  In  lune  2004,  the  Defense  Modeling  & 
Simulation  Office  stood  up  the  M&S  Community  of 
Interest  and  chartered  its  activities  with  an  Operating 
Guideline. 

The  mission  is  to  establish  an  M&S  COI,  ensure  the 
integration  of  M&S  services  into  the  GIG,  and  provide 
a  forum  for  the  M&S  community  to  work  within  the 
COI  to  influence,  advise,  and  educate  the  more  global 
community  with  regard  to  M&S.  The  purpose  is  to 
identify  M&S  web-based  services  for  inclusion  in  the 
GIG,  make  M&S  data  and  services  visible  to  the  GIG 
user  community,  and  to  coordinate  with  other  COIs. 
Like  other  COIs,  M&S  will  manage  its  Metadata  regis¬ 
try,  establish  taxonomies  and  ontologies  to  enable  dis¬ 
covery  and  retrieval  services,  and  conduct  prototype 
experiments  or  demonstration  exploring  the  most  ap¬ 
propriate  services  to  enable  GIG  users  in  the  key  tasks 


of  planning,  training,  sense-making  and  decision  mak¬ 
ing.  To  be  effective  the  M&S  COI  must  promote  Ser¬ 
vice  and  loint  collaboration  in  the  use  of  emerging 
technology  to  adapt  services  for  the  GIG  and  recom¬ 
mend  standards  and  architectures  that  will  best  support 
M&S  as  and  Enterprise  Service.  Coordination  across 
other  communities  will  be  critical  as  M&S  has  roles 
that  span  several  domains.  The  final  shape  of  M&S 
services  will  depend  upon  the  design  and  execution  of 
near-term  proof  of  principle  demonstrations. 

DMSO  chairs  the  M&S  COI,  which  will  include  repre¬ 
sentation  from  the  stakeholders  of  M&S  across  the 
DoD.  Like  the  COI  the  membership  is  under  construc¬ 
tion  and  is  expected  to  be  flexible,  expanding  to  in¬ 
clude  new  participants  with  services  to  provide  or  users 
with  needs  to  be  addressed. 

High  Level  Architecture 

IEEE1516  High  Level  Architecture  (HLA)  standard  is 
currently  under  review  to  identify  necessary  improve¬ 
ments.  The  advent  of  the  GIG  will  influence  the 
evaluation  of  web-based  standards  and  how  they  will 
play  with  the  HLA  as  it  is  evolved. 

Of  particular  interest  is  to  make  the  concepts  of  the 
High  Level  Architecture  generally  available  to  the  GIG 
users  interested  in  distributed  simulation  applications. 
To  this  end,  a  web-based  version  of  HLA  software 
products,  in  particular  the  Runtime  Infrastructure 
(RTI),  in  the  Core  Enterprise  Service  domain  is  an  op¬ 
tion  currently  considered. 

Common  Reference  Data  Models:  C2IEDM 

The  DoD  Net-Centric  Data  Strategy  explicitly  excludes 
the  development  of  a  common  enterprise-wide  data 
model.  The  objective  is  to  develop  composable  ser¬ 
vices  that  are  location  independent  and  loosely  coupled 
based  on  standardized  service  support  environments. 
The  use  of  metadata  supporting  mediation  services  is 
the  current  way  to  go. 

However,  in  order  to  generate  composable  solutions, 
common  reference  models  are  necessary,  as  they  en¬ 
able  semantic  interoperability,  i.e.,  the  services  share 
the  same  interpretation  of  the  exchanged  data.  These 
reference  models  can  be  implicit  (common  sense)  or 
explicit  (model  based  data  management).  While  not 
yet  established,  the  explicit  common  reference  model  is 
the  approach  recommended  by  the  authors.  In  addi¬ 
tion,  this  approach  is  already  well  established  by  the 
Data  Management  instances  of  NATO. 
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Based  on  the  positive  results  within  NATO,  the  Com¬ 
mand  and  Control  Information  Exchange  Data  Model 
(C2IEDM)  has  been  identified  as  a  promising  starting 
point  for  evolving  a  common  reference  model  in  the 
military  domain,  and  in  particular,  in  command  and 
control.  The  Joint  and  Combined  nature  of  C2IEDM  is 
of  particular  interest  for  projects  like  the  Joint  National 
Training  Capability  (JNTC).  The  applicability  in  the 
net-centric  context  of  NATO  was  shown  in  the  ongo¬ 
ing  Multilateral  Interoperability  Program  (MIP).  The 
use  of  C2IEDM  as  a  hub  for  a  common  reference 
model  is  considered  by  various  experts  within  ADUSD 
(Interoperability  &  Network  Centric  Warfare)/ 
ODUSD  (Advanced  Systems  &  Concepts)  and  was 
presented  on  several  workshops.  An  expert  workshop 
found  that  the  use  of  C2IEDM  to  address  challenges  of 
interoperability  and  composability  in  M&S  was  more 
than  feasible.  Work  using  C2IEDM  is  now  underway 
in  linking  M&S  applications  to  operational  databases. 

SUMMARY 

The  GIG  is  coming  and  while  we  do  not  now  know  its 
final  shape,  we  know  it  will  be  based  on  a  service- 
oriented  architecture  that  will  be  enabled  by  web  stan¬ 
dards.  M&S  is  a  key  component  in  transformation  and 
to  live  up  to  it’s  potential,  must  move  with  the  war¬ 
fighter  to  this  new  information  environment.  Over  the 
past  two  years,  the  XMSF  project  has  conducted  a  se¬ 
ries  of  experiments  that  have  tested  the  viability  of  web 
standards  to  support  critical  M&S  functions.  Based  on 
the  positive  results  of  these  endeavors  and  the  need  to 
play  as  an  equal  partner  with  the  warfighter  in  his  IT 
environment,  DMSO  is  creating  the  M&S  COI.  It  is 
through  this  COI  that  the  M&S  community  will  have  a 
voice  in  the  evolution  of  standards,  taxonomies,  on¬ 
tologies,  name  spaces,  registries  and  services  that  will 
form  our  common  GIG  environment. 
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